home *** CD-ROM | disk | FTP | other *** search
/ SIGGRAPH 1996: Proceedings / SIGGRAPH 1996: Proceedings.iso / pc / papers / levoy / light.trf < prev    next >
Text File  |  1996-05-08  |  63KB  |  1,277 lines

  1. .po 0.75i
  2. .ll 7.0i
  3. .ls 1
  4. .nr tm 4v
  5. .nr bm 6v
  6. .nr pp 9
  7. .nr sp 13
  8. \" Section names
  9. .nr RP 2    representation
  10. .nr CR 3    creation
  11. .nr CP 4    compression
  12. .nr DS 5    display
  13. .nr RE 6    results
  14. \" Figure names
  15. .nr LI 1    lightslab
  16. .nr RT 2    rtheta
  17. .nr TI 3    tiling
  18. .nr SA 4    sampling
  19. .nr CA 5    camera
  20. .nr CO 6    coherence    (aka uvst)
  21. .nr FI 7    filter
  22. .nr AP 8    aperture
  23. .nr GA 9    gantry
  24. .nr LT 10    lighting
  25. .nr CM 11    compression
  26. .nr DI 12    display        (aka inversemap, now texture.eps)
  27. .nr IN 13    interpolation
  28. .nr LF 14    lightfields
  29. .nr VQ 15    vqlightfields
  30. .EQ
  31. delim $$
  32. .EN
  33. \".i
  34. \".ps 11
  35. \".(b
  36. \"                                    To appear in SIGGRAPH '96
  37. \".)b
  38. .nr tm 4v
  39. \"    comment out page numbers for final
  40. \".fo ''%'\n(mo/\n(dy/\n(yr'
  41. .fo ''%''
  42. .ps 16
  43. .b
  44. .(b C
  45. Light Field Rendering
  46. .)b
  47. .r
  48. .ps 12
  49. .(b C
  50. Marc Levoy and Pat Hanrahan
  51. Computer Science Department
  52. Stanford University
  53.  
  54. .)b
  55. .2c 0.33i
  56. .uh Abstract
  57. .pp
  58. A number of techniques have been proposed for flying through scenes by
  59. redisplaying previously rendered or digitized views.  Techniques have also been
  60. proposed for interpolating between views by warping input images, using
  61. depth information or correspondences between multiple images.  In this paper,
  62. we describe a simple and robust method for generating new views from arbitrary
  63. camera positions without depth information or feature matching, simply by
  64. combining and resampling the available images.  The key to this technique lies
  65. in interpreting the input images as 2D slices of a 4D function - the light
  66. field.  This function completely characterizes the flow of light through
  67. unobstructed space in a static scene with fixed illumination.
  68. .pp
  69. We describe a sampled representation for light fields that allows for both
  70. efficient creation and display of inward and outward looking views.  We have
  71. created light fields from large arrays of both rendered and digitized images.
  72. The latter are acquired using a video camera mounted on a computer-controlled
  73. gantry.  Once a light field has been created, new views may be constructed in
  74. real time by extracting slices in appropriate directions.  Since the success of
  75. the method depends on having a high sample rate, we describe a compression
  76. system that is able to compress the light fields we have generated by more than
  77. a factor of 100:1 with very little loss of fidelity.  We also address the
  78. issues of antialiasing during creation, and resampling during slice extraction.
  79. .lp
  80. .b "CR Categories:"
  81. I.3.2 [Computer Graphics]: Picture/Image Generation \(em
  82. \fIDigitizing and scanning\fP, \fIViewing algorithms\fP;
  83. I.4.2 [Computer Graphics]: Compression \(em
  84. \fIApproximate methods\fP
  85. .lp
  86. .b "Additional keywords:"
  87. image-based rendering, light field, holographic stereogram, vector
  88. quantization, epipolar analysis
  89. .(f
  90. .lp
  91. .sz -2p
  92. Address:  Gates Computer Science Building 3B                     levoy@cs.stanford.edu
  93.                  Stanford University                                           hanrahan@cs.stanford.edu      
  94. .br
  95.                  Stanford, CA  94305                              http://www-graphics.stanford.edu
  96. .br
  97. .sz +2p
  98. .sp 0.5i
  99. .)f
  100. .sh 1 "Introduction
  101. .pp
  102. Traditionally the input to a 3D graphics system is a scene consisting of
  103. geometric primitives composed of different materials and a set of lights.
  104. Based on this input specification, the rendering system computes and outputs an
  105. image. Recently a new approach to rendering has emerged: \fIimage-based
  106. rendering\fP. Image-based rendering systems generate different views of an
  107. environment from a set of pre-acquired imagery. There are several advantages to
  108. this approach:
  109. .bu
  110. The display algorithms for image-based rendering require modest computational
  111. resources and are thus suitable for real-time implementation on workstations
  112. and personal computers.
  113. .bu
  114. The cost of interactively viewing the scene is independent of scene
  115. complexity.
  116. .bu
  117. The source of the pre-acquired images can be from a real or virtual
  118. environment, i.e. from digitized photographs or from rendered models.  In fact,
  119. the two can be mixed together.
  120. .pp
  121. The forerunner to these techniques is the use of environment maps to capture
  122. the incoming light in a texture map [Blinn76, Greene86].  An environment map
  123. records the incident light arriving from all directions at a point.  The
  124. original use of environment maps was to efficiently approximate reflections of
  125. the environment on a surface.  However, environment maps also may be used to
  126. quickly display any outward looking view of the environment from a fixed
  127. location but at a variable orientation.  This is the basis of the Apple
  128. QuickTimeVR system [Chen95].  In this system environment maps are created at
  129. key locations in the scene.  The user is able to navigate discretely from
  130. location to location, and while at each location continuously change the
  131. viewing direction.
  132. .pp
  133. The major limitation of rendering systems based on environment maps is that the
  134. viewpoint is fixed.  One way to relax this fixed position constraint is to use
  135. view interpolation [Chen93, Greene94, Fuchs94, McMillan95a, McMillan95b,
  136. Narayanan95].  Most of these methods require a depth value for each pixel in
  137. the environment map, which is easily provided if the environment maps are
  138. synthetic images. Given the depth value it is possible to reproject points in
  139. the environment map from different vantage points to warp between multiple
  140. images.  The key challenge in this warping approach is to "fill in the gaps"
  141. when previously occluded areas become visible.
  142. .pp
  143. Another approach to interpolating between acquired images is to find
  144. corresponding points in the two [Laveau94, McMillan95b, Seitz95].  If the
  145. positions of the cameras are known, this is equivalent to finding the depth
  146. values of the corresponding points. Automatically finding correspondences
  147. between pairs of images is the classic problem of stereo vision, and
  148. unfortunately although many algorithms exist, these algorithms are fairly
  149. fragile and may not always find the correct correspondences.
  150. .pp
  151. In this paper we propose a new technique that is robust and allows much more
  152. freedom in the range of possible views. The major idea behind the technique is
  153. a representation of the \fIlight field\fP, the radiance as a function of
  154. position and direction, in regions of space free of occluders (free space).  In
  155. free space, the light field is a 4D, not a 5D function.  An image is a two
  156. dimensional slice of the 4D light field.  Creating a light field from a set of
  157. images corresponds to inserting each 2D slice into the 4D light field
  158. representation.  Similarly, generating new views corresponds to extracting and
  159. resampling a slice.
  160. .pp
  161. Generating a new image from a light field is quite different than previous view
  162. interpolation approaches.  First, the new image is generally formed from many
  163. different pieces of the original input images, and need not look like any of
  164. them.  Second, no model information, such as depth values or image
  165. correspondences, is needed to extract the image values.  Third, image
  166. generation involves only resampling, a simple linear process.
  167. .pp
  168. This representation of the light field is similar to the epipolar volumes used
  169. in computer vision [Bolles87] and to horizontal-parallax-only holographic
  170. stereograms [Benton83].  An epipolar volume is formed from an array of images
  171. created by translating a camera in equal increments in a single direction.
  172. Such a representation has recently been used to perform view interpolation
  173. [Katayama95].  A holographic stereogram is formed by exposing a piece of film
  174. to an array of images captured by a camera moving sideways.  Halle has
  175. discussed how to set the camera aperture to properly acquire images for
  176. holographic stereograms [Halle94], and that theory is applicable to this work.
  177. Gavin Miller has also recognized the potential synergy between true 3D display
  178. technologies and computer graphics algorithms [Miller95].
  179. .pp
  180. There are several major challenges to using the light field approach to view 3D
  181. scenes on a graphics workstation.  First, there is the choice of
  182. parameterization and representation of the light field. Related to this is the
  183. choice of sampling pattern for the field.  Second, there is the issue of how to
  184. generate or acquire the light field.  Third, there is the problem of fast
  185. generation of different views.  This requires that the slice representing
  186. rays through a point be easily extracted, and that the slice be properly
  187. resampled to avoid artifacts in the final image.  Fourth, the obvious
  188. disadvantage of this approach is the large amount of data that may be
  189. required. Intuitively one suspects that the light field is coherent and that it
  190. may be compressed greatly.  In the remaining sections we discuss these issues
  191. and our proposed solutions.
  192. .sh 1 "Representation"
  193. .pp
  194. We define the light field as the radiance at a point in a given direction.
  195. Note that our definition is equivalent to the \fIplenoptic function\fP
  196. introduced by Adelson and Bergen [Adelson91].  The phrase light field was
  197. coined by A. Gershun in his classic paper describing the radiometric properties
  198. of light in a space [Gershun36].$^sup 1~~$  McMillan and Bishop [McMillan95b]
  199. discuss the representation of 5D light fields as a set of panoramic images at
  200. different 3D locations.
  201. .(f
  202. .lp
  203. .sz -2p
  204. $^sup 1$ For those familiar with Gershun's paper, he actually uses the term
  205. light field to mean the irradiance vector as a function of position.  For this
  206. reason P. Moon in a later book [Moon81] uses the term photic field to denote
  207. what we call the light field.
  208. .sz +2p
  209. .)f
  210. .pp
  211. However, the 5D representation may be reduced to 4D in free space (regions free
  212. of occluders).  This is a consequence of the fact that the radiance does not
  213. change along a line unless blocked. 4D light fields may be interpreted as
  214. functions on the space of oriented lines.  The redundancy of the 5D
  215. representation is undesirable for two reasons: first, redundancy increases the
  216. size of the total dataset, and second, redundancy complicates the
  217. reconstruction of the radiance function from its samples.  This reduction in
  218. dimension has been used to simplify the representation of radiance emitted by
  219. luminaires [Levin71, Ashdown93].  For the remainder of this paper we will be
  220. only concerned with 4D light fields.
  221. .pp
  222. Although restricting the validity of the representation to free space may seem
  223. like a limitation, there are two common situations where this assumption is
  224. useful.  First, most geometric models are bounded.  In this case free space is
  225. the region outside the convex hull of the object, and hence all views of an
  226. object from outside its convex hull may be generated from a 4D light field.
  227. Second, if we are moving through an architectural model or an outdoor scene we
  228. are usually moving through a region of free space; therefore, any view from
  229. inside this region, of objects outside the region, may be generated.
  230. .(z L
  231. \".PSPIC /u/hanrahan/lightfield/figs/lightslab.eps 2.5
  232. .PSPIC /u/levoy/lightfigs/lightslab.eps 2.5
  233. .xl 3.125i
  234. .ip " " 0.125i
  235. .ps 8
  236. .b "Figure \n(LI:"
  237. The light slab representation.
  238. .)z
  239. .pp
  240. The major issue in choosing a representation of the 4D light field is how to
  241. parameterize the space of oriented lines. There are several issues in choosing
  242. the parameterization:
  243. .ba +0.125i
  244. .lp
  245. \fBEfficient calculation.\fP The computation of the position of a line from its
  246. parameters should be fast. More importantly, for the purposes of calculating
  247. new views, it should be easy to compute the line parameters given the viewing
  248. transformation and a pixel location.
  249. .lp
  250. \fBControl over the set of lines.\fP The space of all lines is infinite, but
  251. only a finite subset of line space is ever needed.  For example, in the case of
  252. viewing an object we need only lines intersecting the convex hull of the
  253. object.  Thus, there should be an intuitive connection between the actual lines
  254. in 3-space and line parameters.
  255. .lp
  256. \fBUniform sampling.\fP Given equally spaced samples in line parameter space,
  257. the pattern of lines in 3-space should also be uniform.  In this sense, a
  258. uniform sampling pattern is one where the \fInumber of lines\fP in intervals
  259. between samples is constant everywhere.  Note that the correct measure for
  260. number of lines is related to the form factor kernel [Sbert93].
  261. .ba 0
  262. .pp
  263. The solution we propose is to parameterize lines by their intersections with
  264. two planes in arbitrary position (see figure \n(LI).  By convention, the
  265. coordinate system on the first plane is $(u,v)$ and on the second plane is
  266. $(s,t)$.  An oriented line is defined by connecting a point on the uv plane to
  267. a point on the st plane.  In practice we restrict $u$, $v$, $s$, and $t$ to lie
  268. between 0 and 1, and thus points on each plane are restricted to lie within a
  269. convex quadrilateral.  We call this representation a \fIlight slab\fP.
  270. Intuitively, a light slab represents the beam of light entering one
  271. quadrilateral and exiting another quadrilateral.
  272. .pp
  273. A nice feature of this representation is that one of the planes may be placed
  274. at infinity.  This is convenient since then lines may be parameterized by a
  275. point and a direction.  The latter will prove useful for constructing light
  276. fields either from orthographic images or images with a fixed field of view.
  277. Furthermore, if all calculations are performed using homogeneous coordinates,
  278. the two cases may be handled at no additional cost.
  279. .(z L
  280. .PSPIC /u/levoy/lightfigs/rtheta.eps 2.4
  281. .lp
  282. .ps 8
  283. .b "Figure \n(RT:"
  284. Definition of the line space we use to visualize sets of light rays.  Each
  285. oriented line in Cartesian space (at left) is represented in line space (at
  286. right) by a point.  To simplify the visualizations, we show only lines in 2D;
  287. the extension to 3D is straightforward.
  288. .)z
  289. .(z L
  290. \"    .PSPIC /u/levoy/lightfigs/tiling.eps 3.0
  291. .PSPIC /u/levoy/lightfigs/tiling_preview.eps 3.0
  292. .lp
  293. .ps 8
  294. .b "Figure \n(TI:"
  295. Using line space to visualize ray coverage.  (a) shows a single light slab.
  296. Light rays (drawn in gray) connect points on two defining lines (drawn in red
  297. and green).  (c) shows an arrangement of four rotated copies of (a).  (b) and
  298. (d) show the corresponding line space visualizations.  For any set of lines in
  299. Cartesian space, the envelope formed by the corresponding points in line space
  300. indicates our coverage of position and direction; ideally the coverage should
  301. be complete in $theta$ and as wide as possible in $r$.  As these figures show,
  302. the single slab in (a) does not provide full coverage in $theta$, but the
  303. four-slab arrangement in (c) does.  (c) is, however, narrow in $r$.  Such an
  304. arrangement is suitable for inward-looking views of a small object placed at
  305. the origin.  It was used to generate the lion light field in figure \n(LFd.
  306. .hl
  307. .)z
  308. .pp
  309. A big advantage of this representation is the efficiency of geometric
  310. calculations. Mapping from $(u,v)$ to points on the plane is a projective map
  311. and involves only linear algebra (multiplying by a 3x3 matrix).
  312. .(z L
  313. \"    .PSPIC /u/levoy/lightfigs/sampling.eps 2.9
  314. .PSPIC /u/levoy/lightfigs/sampling_preview.eps 2.9
  315. .lp
  316. .ps 8
  317. .b "Figure \n(SA:"
  318. Using line space to visualize sampling uniformity.  (a) shows a light slab
  319. defined by two lines at right angles.  (c) shows a light slab where one
  320. defining line is at infinity.  This arrangement generates rays passing through
  321. the other defining line with an angle between -45\(de and +45\(de.  (b) and (d)
  322. show the corresponding line space visualizations.  Our use of $(r, theta )$ to
  323. parameterize line space has the property that equal areas in line space
  324. correspond to equally dense sampling of position and orientation in Cartesian
  325. space; ideally the density of points in line space should be uniform.  As these
  326. figures show, the singularity at the corner in (a) leads to a highly nonuniform
  327. and therefore inefficient sampling pattern, indicated by dark areas in (b) at
  328. angles of $0$ and $- pi / 2$.  (c) generates a more uniform set of lines.
  329. Although (c) does not provide full coverage of $theta$, four rotated copies do.
  330. Such an arrangement is suitable for outward-looking views by an observer
  331. standing near the origin.  It was used to generate the hallway light field in
  332. figure \n(LFc.
  333. .hl
  334. .)z
  335. More importantly, as will be discussed in section \n(DS, the inverse mapping
  336. from an image pixel $(x,y)$ to $(u,v,s,t)$ is also a projective map.  Methods
  337. using spherical or cylindrical coordinates require substantially more
  338. computation.
  339. .pp
  340. Many properties of light fields are easier to understand in line space
  341. (figures \n(RT through \n(SA).  In line space, each oriented line is
  342. represented by a point and each set of lines by a region.  In particular, the
  343. set of lines represented by a light slab and the set of lines intersecting the
  344. convex hull of an object are both regions in line space.  All views of an
  345. object could be generated from one light slab if its set of lines include all
  346. lines intersecting the convex hull of the object.  Unfortunately, this is not
  347. possible.  Therefore, it takes multiple light slabs to represent all possible
  348. views of an object.  We therefore tile line space with a collection of light
  349. slabs, as shown in figure \n(TI.
  350. .pp
  351. An important issue related to the parameterization is the sampling pattern.
  352. Assuming that all views are equally likely to be generated, then any line is
  353. equally likely to be needed.  Thus all regions of line space should have an
  354. equal density of samples.  Figure \n(SA shows the density of samples in line
  355. space for different arrangements of slabs.  Note that no slab arrangement is
  356. perfect: arrangements with a singularity such as two polygons joined at a
  357. corner (\n(SAa) are bad and should be avoided, whereas slabs formed from
  358. parallel planes (\n(TIa) generate fairly uniform patterns.  In addition,
  359. arrangements where one plane is at infinity (\n(SAc) are better than those with
  360. two finite planes (\n(TIa).  Finally, because of symmetry the spacing of
  361. samples in uv should in general be the same as st.  However, if the observer is
  362. likely to stand near the uv plane, then it may be acceptable to sample uv less
  363. frequently than st.
  364. .sh 1 "Creation of light fields"
  365. .(z L
  366. .xl 7.0i
  367. .PSPIC /u/levoy/lightfigs/coherence_preview.eps 6.0
  368. .lp
  369. .ps 8
  370. .b "Figure \n(CO:"
  371. Two visualizations of a light field.  (a) Each image in the array represents
  372. the rays arriving at one point on the uv plane from all points on the st plane,
  373. as shown at left.  (b) Each image represents the rays leaving one point on the
  374. st plane bound for all points on the uv plane.  The images in (a) are off-axis
  375. (i.e. sheared) perspective views of the scene, while the images in (b) look
  376. like reflectance maps.  The latter occurs because the object has been placed
  377. astride the focal plane, making sets of rays leaving points on the focal
  378. plane similar in character to sets of rays leaving points on the object.
  379. .)z
  380. .pp
  381. In this section we discuss the creation of both virtual light fields (from
  382. rendered images) and real light fields (from digitized images).  One method
  383. to create a light field would be to choose a 4D sampling pattern, and for each
  384. line sample, find the radiance. This is easily done directly for virtual
  385. environments by a ray tracer. This could also be done in a real environment
  386. with a spot radiometer, but it would be very tedious. A more practical way to
  387. generate light fields is to assemble a collection of images.
  388. .sh 2 "From rendered images"
  389. .(z L
  390. \".PSPIC /u/hanrahan/lightfield/figs/camera.eps 2.6
  391. .PSPIC /u/levoy/lightfigs/mycamera.eps 2.6
  392. .xl 3.125i
  393. .ip " " 0.125i
  394. .ps 8
  395. .b "Figure \n(CA:"
  396. The viewing geometry used to create a light slab from an array of
  397. perspective images.
  398. .)z
  399. .pp
  400. For a virtual environment, a light slab is easily generated simply by rendering
  401. a 2D array of images.  Each image represents a slice of the 4D light slab at a
  402. fixed uv value and is formed by placing the center of projection of the virtual
  403. camera at the sample location on the uv plane.  The only issue is that the xy
  404. samples of each image must correspond exactly with the st samples.  This is
  405. easily done by performing a sheared perspective projection (figure \n(CA)
  406. similar to that used to generate a stereo pair of images.  Figure \n(CO shows
  407. the resulting 4D light field, which can be visualized either as a uv array of
  408. st images or as an st array of uv images.
  409. .pp
  410. Two other viewing geometries are useful.  A light slab may be formed from a 2D
  411. array of orthographic views.  This can be modeled by placing the uv plane at
  412. infinity, as shown in figure \n(SAc.  In this case, each uv sample corresponds
  413. to the direction of a parallel projection.  Again, the only issue is to align
  414. the xy and st samples of the image with the st quadrilateral.  The other useful
  415. geometry consists of a 2D array of outward looking (non-sheared) perspective
  416. views with fixed field of view.  In this case, each image is a slice of the
  417. light slab with the st plane at infinity.  The fact that all these cases are
  418. equally easy to handle with light slabs attests to the elegance of projective
  419. geometry.  Light fields using each arrangement are presented in section \n(RE
  420. and illustrated in figure \n(LF.
  421. .(z L
  422. \".PSPIC /u/hanrahan/lightfield/figs/filter.eps 3.26
  423. .PSPIC /u/levoy/lightfigs/myfilter.eps 3.26
  424. .xl 3.125i
  425. .ip " " 0.125i
  426. .ps 8
  427. .b "Figure \n(FI:"
  428. Prefiltering a light field.  To avoid aliasing, a 4D low pass filter must be
  429. applied to the radiance function.
  430. .)z
  431. .pp
  432. As with any sampling process, sampling a light field may lead to aliasing since
  433. typical light fields contain high frequencies.  Fortunately, the effects of
  434. aliasing may be alleviated by filtering before sampling.  In the case of a
  435. light field, a 4D filter in the space of lines must be employed (see figure
  436. \n(FI).  Assuming a box filter, a weighted average of the radiances on all
  437. lines connecting sample squares in the uv and st planes must be computed.  If a
  438. camera is placed on the uv plane and focussed on the st plane, then the
  439. filtering process corresponds to integrating both over a pixel corresponding to
  440. an st sample, and an aperture equal in size to a uv sample, as shown in figure
  441. \n(AP.  The theory behind this filtering process has been discussed in the
  442. context of holographic stereograms by Halle [Halle94].
  443. .(z L
  444. \".PSPIC /u/hanrahan/lightfield/figs/aperture.eps 2.4
  445. .PSPIC /u/levoy/lightfigs/myaperture.eps 2.4
  446. .xl 3.125i
  447. .ip " " 0.125i
  448. .ps 8
  449. .b "Figure \n(AP:"
  450. Prefiltering using an aperture.  This figure shows a camera focused on the st
  451. plane with an aperture on the uv plane whose size is equal to the uv sample
  452. spacing.  A hypothetical film plane is drawn behind the aperture.  Ignore the
  453. aperture for a moment (consider a pinhole camera that precisely images the st
  454. plane onto the film plane).  Then integrating over a pixel on the film plane is
  455. equivalent to integrating over an st region bounded by the pixel.  Now consider
  456. fixing a point on the film plane while using a finite sized aperture (recall
  457. that all rays from a point on the film through the aperture are focussed on a
  458. single point on the focal plane).  Then integrating over the aperture
  459. corresponds to integrating all rays through the uv region bounded by the
  460. aperture.  Therefore, by simultaneously integrating over both the pixel and the
  461. aperture, the proper 4D integral is computed.
  462. .hl
  463. .)z
  464. .pp
  465. Note that although prefiltering has the desired effect of antialiasing the
  466. light field, it has what at first seems like an undesirable side effect \(em
  467. introducing blurriness due to depth of field.  However, this blurriness is
  468. precisely correct for the situation.  Recall what happens when creating a pair
  469. of images from two adjacent camera locations on the uv plane: a given object
  470. point will project to different locations, potentially several pixels apart, in
  471. these two images.  The distance between the two projected locations is called
  472. the stereo disparity.  Extending this idea to multiple camera locations
  473. produces a sequence of images in which the object appears to jump by a distance
  474. equal to the disparity.  This jumping is aliasing.  Recall now that taking an
  475. image with a finite aperture causes points out of focus to be blurred on the
  476. film plane by a circle of confusion.  Setting the diameter of the aperture to
  477. the spacing between camera locations causes the circle of confusion for each
  478. object point to be equal in size to its stereo disparity.  This replaces the
  479. jumping with a sequence of blurred images.  Thus, we are removing aliasing by
  480. employing finite depth of field.
  481. .pp
  482. The necessity for prefiltering can also be understood in line space.  Recall
  483. from our earlier discussion that samples of the light field correspond to
  484. points in line space.  Having a finite depth of field with an aperture equal in
  485. size to the uv sample spacing insures that each sample adequately covers the
  486. interval between these line space points.  Too small or too large an aperture
  487. yields gaps or overlaps in line space coverage, resulting in views that are
  488. either aliased or excessively blurry, respectively.
  489. .sh 2 "From digitized images"
  490. .pp
  491. Digitizing the imagery required to build a light field of a physical scene is a
  492. formidable engineering problem.  The number of images required is large
  493. (hundreds or thousands), so the process must be automated or at least
  494. computer-assisted.  Moreover, the lighting must be controlled to insure a
  495. static light field, yet flexible enough to properly illuminate the scene, all
  496. the while staying clear of the camera to avoid unwanted shadows.  Finally, real
  497. optical systems impose constraints on angle of view, focal distance, depth of
  498. field, and aperture, all of which must be managed.  Similar issues have been
  499. faced in the construction of devices for performing near-field photometric
  500. measurements of luminaires [Ashdown93].  In the following paragraphs, we
  501. enumerate the major design decisions we faced in this endeavor and the
  502. solutions we adopted.
  503. .ba +0.125i
  504. .(z L
  505. .PSPIC  /u/levoy/lightfigs/gantry_preview.eps 2.25
  506. .xl 3.125i
  507. .ip " " 0.125i
  508. .ps 8
  509. .b "Figure \n(GA:"
  510. Our prototype camera gantry.  A modified Cyberware MS motion platform with
  511. additional stepping motors from LinTech and Parker provide four degrees of
  512. freedom: horizontal and vertical translation, pan, and tilt.  The camera is a
  513. Panasonic WV-F300 3-CCD video camera with a Canon f/1.7 10-120mm zoom lens.  We
  514. keep it locked off at its widest setting (10mm) and mounted so that the pitch
  515. and yaw axes pass through the center of projection.  While digitizing, the
  516. camera is kept pointed at the center of the focal plane.  Calibrations and
  517. alignments are verified with the aid of a Faro digitizing arm, which is
  518. accurate to 0.3 mm.
  519. .)z
  520. .lp
  521. \fBInward versus outward looking.\fP The first decision to be made was between
  522. a flyaround of a small object and a flythrough of a large-scale scene.  We
  523. judged flyarounds to be the simpler case, so we attacked them first.
  524. .lp
  525. \fBHuman versus computer-controlled.\fP An inexpensive approach to digitizing
  526. light fields is to move a handheld camera through the scene, populating the
  527. field from the resulting images [Gortler96].  This approach necessitates
  528. estimating camera pose at each frame and interpolating the light field from
  529. scattered data - two challenging problems.  To simplify the situation, we
  530. chose instead to build a computer-controlled camera gantry and to digitize
  531. images on a regular grid.
  532. .(z L
  533. .PSPIC  /u/levoy/lightfigs/lighting.eps
  534. .xl 3.125i
  535. .ip " " 0.125i
  536. .ps 8
  537. .b "Figure \n(LT:"
  538. Object and lighting support.  Objects are mounted on a Bogen fluid-head tripod,
  539. which we manually rotate to four orientations spaced 90 degrees apart.
  540. Illumination is provided by two 600W Lowell Omni spotlights attached to a
  541. ceiling-mounted rotating hub that is aligned with the rotation axis of the
  542. tripod.  A stationary 6' x 6' diffuser panel is hung between the spotlights and
  543. the gantry, and the entire apparatus is enclosed in black velvet to eliminate
  544. stray light.
  545. .)z
  546. .lp
  547. \fBSpherical versus planar camera motion.\fP For flyarounds of small objects,
  548. an obvious gantry design consists of two concentric hemicycles, similar to a
  549. gyroscope mounting.  The camera in such a gantry moves along a spherical
  550. surface, always pointing at the center of the sphere.  Apple Computer has
  551. constructed such a gantry to acquire imagery for Quick-Time VR flyarounds
  552. [Chen95].  Unfortunately, the lighting in their system is attached to the
  553. moving camera, so it is unsuitable for acquiring static light fields.  In
  554. general, a spherical gantry has three advantages over a planar gantry: (a) it
  555. is easier to cover the entire range of viewing directions, (b) the sampling
  556. rate in direction space is more uniform, and (c) the distance between the
  557. camera and the object is fixed, providing sharper focus throughout the range of
  558. camera motion.  A planar gantry has two advantages over a spherical gantry: (a)
  559. it is easier to build; the entire structure can be assembled from linear motion
  560. stages, and (b) it is closer to our light slab representation.  For our first
  561. prototype gantry, we chose to build a planar gantry, as shown in figure \n(GA.
  562. .lp
  563. \fBField of view.\fP Our goal was to build a light field that allowed 360
  564. degrees of azimuthal viewing.  To accomplish this using a planar gantry meant
  565. acquiring four slabs each providing 90 degrees.  This can be achieved with a
  566. camera that translates but does not pan or tilt by employing a wide-angle lens.
  567. This solution has two disadvantages: (a) wide-angle lenses exhibit significant
  568. distortion, which must be corrected after acquisition, and (b) this solution
  569. trades off angle of view against sensor resolution.  Another solution is to
  570. employ a view camera in which the sensor and optical system translate in
  571. parallel planes, the former moving faster than the latter.  Horizontal
  572. parallax holographic stereograms are constructed using such a camera
  573. [Halle94].  Incorporating this solution into a gantry that moves both
  574. horizontally and vertically is difficult.  We instead chose to equip our camera
  575. with pan and tilt motors, enabling us to use a narrow-angle lens.  The use of a
  576. rotating camera means that, in order to transfer the acquired image to the
  577. light slab representation, it must be reprojected to lie on a common plane.
  578. This reprojection is equivalent to keystone correction in architectural
  579. photography.
  580. .lp
  581. \fBStandoff distance.\fP A disadvantage of planar gantries is that the distance
  582. from the camera to the object changes as the camera translates across the
  583. plane, making it difficult to keep the object in focus.  The view camera
  584. described above does not suffer from this problem, because the ratio of object
  585. distance to image distance stays constant as the camera translates.  For a
  586. rotating camera, servo-controlled focusing is an option, but changing the focus
  587. of a camera shifts its center of projection and changes the image
  588. magnification, complicating acquisition.  We instead mitigate this problem by
  589. using strong lighting and a small aperture to maximize depth of field.
  590. .lp
  591. \fBSensor rotation.\fP Each sample in a light slab should ideally represent the
  592. integral over a pixel, and these pixels should lie on a common focal plane.  A
  593. view camera satisfies this constraint because its sensor translates in a plane.
  594. Our use of a rotating camera means that the focal plane also rotates.  Assuming
  595. that we resample the images carefully during reprojection, the presence of a
  596. rotated focal plane will introduce no additional error into the light field.
  597. In practice, we have not seen artifacts due to this resampling process.
  598. .lp
  599. \fBAperture size.\fP Each sample in a light slab should also represent the
  600. integral over an aperture equal in size to a uv sample.  Our use of a small
  601. aperture produces a light field with little or no uv antialiasing.  Even fully
  602. open, the apertures of commercial video cameras are small.  We can approximate
  603. the required antialiasing by averaging together some number of adjacent views,
  604. thereby creating a \fIsynthetic aperture\fP.  However, this technique requires
  605. a very dense spacing of views, which in turn requires rapid acquisition.  We do
  606. not currently do this.
  607. .lp
  608. \fBObject support.\fP In order to acquire a 360-degree light field in four
  609. 90-degree segments using a planar gantry, either the gantry or the object must
  610. be rotated to each of four orientations spaced 90 degrees apart.  Given the
  611. massiveness of our gantry, the latter was clearly easier.  For these
  612. experiments, we mounted our objects on a tripod, which we manually rotate
  613. to the four positions as shown in figure \n(LT.
  614. .lp
  615. \fBLighting.\fP Given our decision to rotate the object, satisfying the
  616. requirement for fixed illumination means that either the lighting must exhibit
  617. fourfold symmetry or it must rotate with the object.  We chose the latter
  618. solution, attaching a lighting system to a rotating hub as shown in figure
  619. \n(LT.  Designing a lighting system that stays clear of the gantry, yet
  620. provides enough light to evenly illuminate an object, is a challenging problem.
  621. .ba 0
  622. .pp
  623. Using this gantry, our procedure for acquiring a light field is as follows.
  624. For each of the four orientations, the camera is translated through a regular
  625. grid of camera positions.  At each position, the camera is panned and tilted to
  626. point at the center of the object, which lies along the axis of rotation of the
  627. tripod.  We then acquire an image, and, using standard texture mapping
  628. algorithms, reproject it to lie on a common plane as described earlier.  Table
  629. II gives a typical set of acquisition parameters.  Note that the distance
  630. between camera positions (3.125 cm) exceeds the diameter of the aperture (1.25
  631. mm), underscoring the need for denser spacing and a synthetic aperture.
  632. .sh 1 "Compression"
  633. .pp
  634. Light field arrays are large \(em the largest example in this paper is 1.6 GB.
  635. To make creation, transmission, and display of light fields practical, they
  636. must be compressed.  In choosing from among many available compression
  637. techniques, we were guided by several unique characteristics of light fields:
  638. .ba +0.125i
  639. .lp
  640. \fBData redundancy.\fP A good compression technique removes redundancy from a
  641. signal without affecting its content.  Light fields exhibit redundancy in all
  642. four dimensions.  For example, the smooth regions in figure \n(COa tell us that
  643. this light field contains redundancy in s and t, and the smooth regions in
  644. figure \n(COb tell us that the light field contains redundancy in u and v.  The
  645. former corresponds to our usual notion of interpixel coherence in a perspective
  646. view.  The latter can be interpreted either as the interframe coherence one
  647. expects in a motion sequence or as the smoothness one expects in the
  648. bidirectional reflectance distribution function (BRDF) for a diffuse or
  649. moderately specular surface.  Occlusions introduce discontinuities in both
  650. cases, of course.
  651. .lp
  652. \fBRandom access.\fP Most compression techniques place some constraint on
  653. random access to data.  For example, variable-bitrate coders may require
  654. scanlines, tiles, or frames to be decoded at once.  Examples in this class are
  655. variable-bitrate vector quantization and the Huffman or arithmetic coders used
  656. in JPEG or MPEG.  Predictive coding schemes further complicate random-access
  657. because pixels depend on previously decoded pixels, scanlines, or frames.  This
  658. poses a problem for light fields since the set of samples referenced when
  659. extracting an image from a light field are dispersed in memory.  As the
  660. observer moves, the access patterns change in complex ways.  We therefore seek
  661. a compression technique that supports low-cost random access to individual
  662. samples.
  663. .lp
  664. \fBAsymmetry.\fP Applications of compression can be classified as symmetric or
  665. asymmetric depending on the relative time spent encoding versus decoding.  We
  666. assume that light fields are assembled and compressed ahead of time, making
  667. this an asymmetric application.
  668. .lp
  669. \fBComputational expense.\fP We seek a compression scheme that can be decoded
  670. without hardware assistance.  Although software decoders have been demonstrated
  671. for standards like JPEG and MPEG, these implementations consume the full power
  672. of a modern microprocessor.  In addition to decompression, the display
  673. algorithm has additional work to perform, as will be described in section
  674. \n(DS.  We therefore seek a compression scheme that can be decoded quickly.
  675. .ba 0
  676. .(z L
  677. .PSPIC /u/levoy/lightfigs/compression.eps 3.25
  678. .xl 3.125i
  679. .ip " " 0.125i
  680. .ps 8
  681. .b "Figure \n(CM"
  682. Two-stage compression pipeline.  The light field is partitioned into tiles,
  683. which are encoded using vector quantization to form an array of codebook
  684. indices.  The codebook and the array of indices are further compressed using
  685. Lempel-Ziv coding.  Decompression also occurs in two stages: entropy decoding
  686. as the file is loaded into memory, and dequantization on demand during
  687. interactive viewing.  Typical file sizes are shown beside each stage.
  688. .)z
  689. .pp
  690. The compression scheme we chose was a two-stage pipeline consisting of
  691. fixed-rate vector quantization followed by entropy coding (Lempel-Ziv), as
  692. shown in figure \n(CM.  Following similar motivations, Beers et al. use vector
  693. quantization to compress textures for use in rendering pipelines [Beers96].
  694. .sh 2 "Vector quantization"
  695. .pp
  696. The first stage of our compression pipeline is vector quantization (VQ)
  697. [Gersho92], a lossy compression technique wherein a vector of samples is
  698. quantized to one of a number of predetermined reproduction vectors.  A
  699. reproduction vector is called a codeword, and the set of codewords available to
  700. encode a source is called the codebook, Codebooks are constructed during a
  701. training phase in which the quantizer is asked to find a set of codewords that
  702. best approximates a set of sample vectors, called the training set.  The
  703. quality of a codeword is typically characterized using mean-squared error
  704. (MSE), i.e. the sum over all samples in the vector of the squared difference
  705. between the source sample and the codeword sample.  Once a codebook has been
  706. constructed, encoding consists of partitioning the source into vectors and
  707. finding for each vector the closest approximating codeword from the codebook.
  708. Decoding consists of looking up indices in the codebook and outputting the
  709. codewords found there \(em a very fast operation.  Indeed, decoding speed is
  710. one of the primary advantages of vector quantization.
  711. .pp
  712. In our application, we typically use 2D or 4D tiles of the light field,
  713. yielding 12-dimensional or 48-dimensional vectors, respectively.  The former
  714. takes advantage of coherence in s and t only, while the latter takes advantage
  715. of coherence in all four dimensions.  To maximize image quality, we train on a
  716. representative subset of each light field to be compressed, then transmit the
  717. resulting codebook along with the codeword index array.  Since light fields are
  718. large, even after compression, the additional overhead of transmitting a
  719. codebook is small, typically less than 20%.  We train on a subset rather than
  720. the entire light field to reduce the expense of training.
  721. .pp
  722. The output of vector quantization is a sequence of fixed-rate codebook indices.
  723. Each index is log $N$ bits where $N$ is the number of codewords in the
  724. codebook, so the compression rate of the quantizer is $(k l)~ /~ (log~N)$ where
  725. $k$ is the number of elements per vector (i.e. the dimension), and $l$ is the
  726. number of bits per element, usually 8.  In our application, we typically use
  727. 16384-word codebooks, leading to a compression rate for this stage of the
  728. pipeline of (48 x 8) / (log 16384) = 384 bits / 14 bits = 27:1.  To simplify
  729. decoding, we represent each index using an integral number of bytes, 2 in our
  730. case, which reduces our compression slightly, to 24:1.
  731. .sh 2 "Entropy coding"
  732. .pp
  733. The second stage of our compression pipeline is an entropy coder designed to
  734. decrease the cost of representing high-probability code indices.  Since our
  735. objects are typically rendered or photographed against a constant-color
  736. background, the array contains many tiles that occur with high probability.
  737. For the examples in this paper, we employed gzip, an implementation of
  738. Lempel-Ziv coding [Ziv77].  In this algorithm, the input stream is partitioned
  739. into nonoverlapping blocks while constructing a dictionary of blocks seen thus
  740. far.  Applying gzip to our array of code indices typically gives us an
  741. additional 5:1 compression.  Huffman coding would probably yield slightly
  742. higher compression, but encoding and decoding would be more expensive.  Our
  743. total compression is therefore 24 x 5 = 120:1.  See section \n(RE and table III
  744. for more detail on our compression results.
  745. .sh 2 "Decompression"
  746. .pp
  747. Decompression occurs in two stages.  The first stage \(em gzip decoding \(em is
  748. performed as the file is loaded into memory.  The output of this stage is a
  749. codebook and an array of code indices packed in 16-bit words.  Although some
  750. efficiency has been lost by this decoding, the light field is still compressed
  751. 24:1, and it is now represented in a way that supports random access.
  752. .pp
  753. The second stage \(em dequantization \(em proceeds as follows.  As the observer
  754. moves through the scene, the display engine requests samples of the light
  755. field.  Each request consists of a $(u,v,s,t)$ coordinate tuple.  For each
  756. request, a subscripting calculation is performed to determine which sample tile
  757. is being addressed.  Each tile corresponds to one quantization vector and is
  758. thus represented in the index array by a single entry.  Looking this index up
  759. in the codebook, we find a vector of sample values.  A second subscripting
  760. calculation is then performed, giving us the offset of the requested sample
  761. within the vector.  With the aid of precomputed subscripting tables,
  762. dequantization can be implemented very efficiently.  In our tests,
  763. decompression consumes about 25% of the CPU cycles.
  764. .sh 1 "Display"
  765. .(z L
  766. .PSPIC /u/levoy/lightfigs/display.eps 2.5
  767. .xl 3.125i
  768. .ip " " 0.125i
  769. .b "Figure \n(DI:"
  770. The process of resampling a light slab during display.
  771. .)z
  772. .pp
  773. The final part of the system is a real time viewer that constructs and displays
  774. an image from the light slab given the imaging geometry.  The viewer must
  775. resample a 2D slice of lines from the 4D light field; each line represents a
  776. ray through the eye point and a pixel center as shown in figure \n(DI.  There
  777. are two steps to this process: step 1 consists of computing the $(u,v,s,t)$
  778. line parameters for each image ray, and step 2 consists of resampling the
  779. radiance at those line parameters.
  780. .pp
  781. As mentioned previously, a big advantage of the light slab representation is
  782. the efficiency of the inverse calculation of the line parameters.  Conceptually
  783. the $(u,v)$ and $(s,t)$ parameters may be calculated by determining the point
  784. of intersection of an image ray with each plane.  Thus, any ray tracer could
  785. easily be adapted to use light slabs.  However, a polygonal rendering system
  786. also may be used to view a light slab.  The transformation from image
  787. coordinates $(x,y)$ to both the $(u,v)$ and the $(s,t)$ coordinates is a
  788. projective map.  Therefore, computing the line coordinates can be done using
  789. texture mapping.  The uv quadrilateral is drawn using the current viewing
  790. transformation, and during scan conversion the $(uw,vw,w)$ coordinates at the
  791. corners of the quadrilateral are interpolated.  The resulting $u=uw/w$ and
  792. $v=vw/w$ coordinates at each pixel represent the ray intersection with the uv
  793. quadrilateral. A similar procedure can be used to generate the $(s,t)$
  794. coordinates by drawing the st quadrilateral.  Thus, the inverse transformation
  795. from $(x,y)$ to $(u,v,s,t)$ reduces essentially to two texture coordinate
  796. calculations per ray.  This is cheap and can be done in real time, and is
  797. supported in many rendering systems, both hardware and software.
  798. .(z L
  799. .PSPIC /u/levoy/lightfigs/interpolation_preview.eps 3.4
  800. .xl 3.125i
  801. .ip " " 0.125i
  802. .ps 8
  803. .b "Figure \n(IN:"
  804. The effects of interpolation during slice extraction.  (a) No interpolation.
  805. (b) Linear interpolation in uv only.  (c) Quadralinear interpolation in uvst.
  806. .)z
  807. .pp
  808. Only lines with $(u,v)$ and $(s,t)$ coordinates inside both quadrilaterals are
  809. represented in the light slab. Thus, if the texture coordinates for each plane
  810. are computed by drawing each quadrilaterial one after the other, then only
  811. those pixels that have both valid uv and st coordinates should be looked up in
  812. the light slab array.  Alternatively, the two quadrilaterals may be
  813. simultaneously scan converted in their region of overlap to cut down on
  814. unnecessary calculations; this is the technique that we use in our software
  815. implementation.
  816. .pp
  817. To draw an image of a collection of light slabs, we draw them sequentially.  If
  818. the sets of lines in the collection of light slabs do not overlap, then each
  819. pixel is drawn only once and so this is quite efficient.  To further increase
  820. efficiency, "back-facing" light slabs may be culled.
  821. .pp
  822. The second step involves resampling the radiance.  The ideal resampling process
  823. first reconstructs the function from the original samples, and then applies a
  824. bandpass filter to the reconstructed function to remove high frequencies that
  825. may cause aliasing.  In our system, we approximate the resampling process by
  826. simply interpolating the 4D function from the nearest samples.  This is correct
  827. only if the new sampling rate is greater than the original sampling rate, which
  828. is usually the case when displaying light fields. However, if the image of the
  829. light field is very small, then some form of prefiltering should be applied.
  830. This could easily be done with a 4D variation of the standard mipmapping
  831. algorithm [Williams83].
  832. .pp
  833. Figure \n(IN shows the effect of nearest neighbor versus bilinear interpolation
  834. on the uv plane versus quadrilinear interpolation of the full 4D function.
  835. Quadralinear interpolation coupled with the proper prefiltering generates
  836. images with few aliasing artifacts.  The improvement is particularly dramatic
  837. when the object or camera is moving.  However, quadralinear filtering is more
  838. expensive and can sometimes be avoided.  For example, if the sampling rates
  839. in the uv and st planes are different, and then the benefits of filtering one
  840. plane may be greater than the other plane.
  841. .sh 1 "Results"
  842. .(z
  843. .TS
  844. box;
  845. L|C|C|C|C.
  846.     \fBbuddha    kidney    hallway    lion\fP
  847. _
  848. .T&
  849. L|R|R|R|R.
  850. Number of slabs    1    1    4    4
  851. Images per slab    16x16    64x64    64x32    32x16
  852. Total images    256    4096    8192    2048
  853. Pixels per image    $256 sup 2$    $128 sup 2$    $256 sup 2$    $256 sup 2$
  854. Raw size (MB)    50    201    1608    402
  855. Prefiltering    uvst    st only    uvst    st only
  856. .TE
  857. .xl 3.125i
  858. .ip " " 0.125i
  859. .ps 8
  860. .b "Table I:"
  861. Statistics of the light fields shown in figure \n(LF.
  862. .)z
  863. .pp
  864. Figure \n(LF shows images extracted from four light fields.  The first is a
  865. buddha constructed from rendered images.  The model is an irregular polygon
  866. mesh constructed from range data.  The input images were generated using
  867. RenderMan, which also provided the machinery for computing pixel and aperture
  868. antialiasing.  The light field configuration was a single slab similar to that
  869. shown in figure \n(TIa.
  870. .pp
  871. Our second light field is a human abdomen constructed from volume renderings.
  872. The two tan-colored organs on either side of the spine are the kidneys.  In
  873. this case, the input images were orthographic views, so we employed a slab with
  874. one plane at infinity as shown in figure \n(SAc.  Because an orthographic
  875. image contains rays of constant direction, we generated more input images than
  876. in the first example in order to provide the angular range needed for creating
  877. perspective views.  The images include pixel antialiasing but no aperture
  878. antialiasing.  However, the dense spacing of input images reduces aperture
  879. aliasing artifacts to a minimum.
  880. .(z
  881. .in +0.125i
  882. .TS
  883. box;
  884. L|R.
  885. \fBCamera motion\fP
  886. $~~~$translation per slab    100 cm x 50 cm
  887. $~~~$pan and tilt per slab    90\(de x 45\(de
  888. $~~~$number of slabs    4 slabs 90\(de apart
  889. $~~~$total pan and tilt    360\(de x 45\(de
  890. \fBSampling density\fP
  891. $~~~$distance to object    50 cm
  892. $~~~$camera pan per sample    3.6\(de
  893. $~~~$camera translation per sample    3.125 cm
  894. \fBAperture\fP
  895. $~~~$focal distance of lens    10mm
  896. $~~~$F-number    f/8
  897. $~~~$aperture diameter    1.25 mm
  898. \fBAcquisition time\fP
  899. $~~~$time per image    3 seconds
  900. $~~~$total acquisition time    4 hours
  901. .TE
  902. .in 0
  903. .xl 3.125i
  904. .ip " " 0.125i
  905. .ps 8
  906. .b "Table II:"
  907. Acquisition parameters for the lion light field.  Distance to object and camera
  908. pan per sample are given at the center of the plane of camera motion.  Total
  909. acquisition time includes longer gantry movements at the end of each row and
  910. manual setup time for each of the four orientations.  The aperture diameter is
  911. the focal length divided by the F-number.
  912. .)z
  913. .(z
  914. .in +0.0625i
  915. .TS
  916. box;
  917. L|C|C.
  918.     \fBbuddha    lion\fP
  919. _
  920. .T&
  921. L|R|R.
  922. \fBVector quantization\fP
  923. $~~~$raw size (MB)    50.3    402.7
  924. $~~~$fraction in training set    5%    3%
  925. $~~~$samples per tile    2x2x1x1    2x2x2x2
  926. $~~~$bytes per sample    3    3
  927. $~~~$vector dimension    12    48
  928. $~~~$number of codewords    8192    16384
  929. $~~~$codebook size (MB)    0.1    0.8
  930. $~~~$bytes per codeword index    2    2
  931. $~~~$index array size (MB)    8.4    16.8
  932. $~~~$total size (MB)    8.5    17.6
  933. $~~~$compression rate    6:1    23:1
  934. \fBEntropy coding\fP
  935. $~~~$gzipped codebook (MB)    0.1    0.6
  936. $~~~$gzipped index array (MB)    1.0    2.8
  937. $~~~$total size (MB)    1.1    3.4
  938. $~~~$compression due to gzip    8:1    5:1
  939. $~~~$total compression    45:1    118:1
  940. \fBCompression performance\fP
  941. $~~~$training time    15 mins    4 hrs
  942. $~~~$encoding time    1 mins    8 mins
  943. $~~~$original entropy (bits/pixel)    4.2    2.9
  944. $~~~$image quality (PSNR)    36    27
  945. .TE
  946. .in 0
  947. .xl 3.125i
  948. .ip " " 0.125i
  949. .ps 8
  950. .b "Table III:"
  951. Compression statistics for two light fields.  The buddha was compressed using
  952. 2D tiles of RGB pixels, forming 12-dimensional vectors, and the lion was
  953. compressed using 4D tiles (2D tiles of RGB pixels from each of 2 x 2 adjacent
  954. camera positions), forming 48-dimensional vectors.  Bytes per codeword index
  955. include padding as described in section \n(CP.  Peak signal-to-noise ratio
  956. (PSNR) is computed as $10 log sub 10 ( 255 sup 2 / MSE )$.
  957. .hl
  958. .)z
  959. .pp
  960. Our third example is an outward-looking light field depicting a hallway in
  961. Berkeley's Soda Hall, rendered using a radiosity program.  To allow a full
  962. range of observer motion while optimizing sampling uniformity, we used four
  963. slabs with one plane at infinity, a four-slab version of figure \n(SAc.  The
  964. input images were rendered on an SGI RealityEngine, using the accumulation
  965. buffer to provide both pixel and aperture antialiasing.
  966. .pp
  967. Our last example is a light field constructed from digitized images.  The scene
  968. is of a toy lion, and the light field consists of four slabs as shown in figure
  969. \n(TIc, allowing the observer to walk completely around the object.  The sensor
  970. and optical system provide pixel antialiasing, but the aperture diameter was
  971. too small to provide correct aperture antialiasing.  As a result, the light
  972. field exhibits some aliasing, which appears as double images.  These artifacts
  973. are worst near the head and tail of the lion because of their greater distance
  974. from the axis around which the camera rotated.
  975. .pp
  976. Table I summarizes the statistics of each light field.  Table II gives
  977. additional information on the lion dataset.  Table III gives the performance of
  978. our compression pipeline on two representative datasets.  The buddha was
  979. compressed using a 2D tiling of the light field, yielding a total compression
  980. rate of 45:1.  The lion was compressed using a 4D tiling, yielding a higher
  981. compression rate of 118:1.  During interactive viewing, the compressed buddha
  982. is indistinguishable from the original; the compressed lion exhibits some
  983. artifacts, but only at high magnifications.  Representative images are shown in
  984. figure \n(VQ.  We have also experimented with higher rates.  As a general rule,
  985. the artifacts become objectionable only above 200:1.
  986. .pp
  987. Finally, table IV summarizes the performance of our interactive viewer
  988. operating on the lion light field.  As the table shows, we achieve interactive
  989. playback rates for reasonable image sizes.  Note that the size of the light
  990. field has no effect on playback rate; only the image size matters.  Memory size
  991. is not an issue because the compressed fields are small.
  992. .(z
  993. .TS
  994. box;
  995. L|R|R|R.
  996. \fBDisplay times (ms)    no bilerp    uv lerp    uvst lerp\fP
  997.     _    _    _
  998. $~~~$coordinate calculation    13    13    13
  999. $~~~$sample extraction    14    59    214
  1000. $~~~$overhead    3    3    3
  1001.     _    _    _
  1002. $~~~$total    30    75    230
  1003. .TE
  1004. .xl 3.125i
  1005. .ip " " 0.125i
  1006. .ps 8
  1007. .b "Table IV:"
  1008. Display performance for the lion light field.  Displayed images are 192 x 192
  1009. pixels.  Sample extraction includes VQ decoding and sample interpolation.
  1010. Display overhead includes reading the mouse, computing the observer position,
  1011. and copying the image to the frame buffer.  Timings are for a software-only
  1012. implementation on a 250 MHz MIPS 4400 processor.
  1013. .hl
  1014. .)z
  1015. .sh 1 "Discussion and future work"
  1016. .pp
  1017. We have described a new light field representation, the light slab, for storing
  1018. all the radiance values in free space.  Both inserting images into the field
  1019. and extracting new views from the field involve resampling, a simple and robust
  1020. procedure.  The resulting system is easily implemented on workstations and
  1021. personal computers, requiring modest amounts of memory and cycles. Thus, this
  1022. technique is useful for many applications requiring interaction with 3D scenes.
  1023. .pp
  1024. There are three major limitation of our method.  First, the sampling density
  1025. must be high to avoid excessive blurriness.  This requires rendering or
  1026. acquiring a large number of images, which may take a long time and consume a
  1027. lot of memory.  However, denser sample spacing leads to greater inter-sample
  1028. coherence, so the size of the light field is usually manageable after
  1029. compression.  Second, the observer is restricted to regions of space free of
  1030. occluders.  This limitation can be addressed by stitching together multiple
  1031. light fields based on a partition of the scene geometry into convex regions.
  1032. If we augment light fields to include Z-depth, the regions need not even be
  1033. convex.  Third, the illumination must be fixed.  If we ignore interreflections,
  1034. this limitation can be addressed by augmenting light fields to include surface
  1035. normals and optical properties.  To handle interreflections, we might try
  1036. representing illumination as a superposition of basis functions [Nimeroff94].
  1037. This would correspond in our case to computing a sum of light fields each lit
  1038. with a different illumination function.
  1039. .pp
  1040. It is useful to compare this approach with depth-based or correspondence-based
  1041. view interpolation.  In these systems, a 3D model is created to improve quality
  1042. of the interpolation and hence decrease the number of pre-acquired images.  In
  1043. our approach, a much larger number of images is acquired, and at first this
  1044. seems like a disadvantage.  However, because of the 3D structure of the light
  1045. field, simple compression schemes are able to find and exploit this same 3D
  1046. structure.  In our case, simple 4D block coding leads to compression rates of
  1047. over 100:1.  Given the success of the compression, a high density compressed
  1048. light field has an advantage over other approaches because the resampling
  1049. process is simpler, and no explicit 3D structure must be found or stored.
  1050. .pp
  1051. There are many representations for light used in computer graphics and computer
  1052. vision, for example, images, shadow and environment maps, light sources,
  1053. radiosity and radiance basis functions, and ray tracing procedures. However,
  1054. abstract light representations have not been systematically studied in the same
  1055. way as modeling and display primitives.  A fruitful line of future research
  1056. would be to reexamine these representations from first principles.  Such
  1057. reexaminations may in turn lead to new methods for the central problems in
  1058. these fields.
  1059. .pp
  1060. Another area of future research is the design of instrumentation for
  1061. acquisition.  A large parallel array of cameras connected to a parallel
  1062. computer could be built to acquire and compress a light field in real time.  In
  1063. the short term, there are many interesting engineering issues in designing and
  1064. building gantries to move a small number of cameras and lights to sequentially
  1065. acquire both inward- and outward-looking light fields.  This same
  1066. instrumentation could lead to breakthroughs in both 3D shape acquisition and
  1067. reflection measurements.  In fact, the interaction of light with any object can
  1068. be represented as a higher-dimensional interaction matrix; acquiring,
  1069. compressing, and manipulating such representations are a fruitful area for
  1070. investigation.
  1071. .sh 1 "Acknowledgements"
  1072. .pp
  1073. We would like to thank David Addleman and George Dabrowski of Cyberware for
  1074. helping us design and build the camera gantry, Craig Kolb and James Davis for
  1075. helping us calibrate it, Brian Curless for scanning the buddha, Julie Dorsey
  1076. for shading it and allowing us to use it, Carlo Sequin for the Soda Hall model,
  1077. Seth Teller, Celeste Fowler, and Thomas Funkhauser for its radiosity solution,
  1078. Lucas Pereira for rendering it, Benjamin Zhu for reimplementing our
  1079. hardware-accelerated viewer in software, and Navin Chaddha for his vector
  1080. quantization code.  We also wish to thank Eric Chen and Michael Chen for
  1081. allowing us to examine the Apple ObjectMaker, and Alain Fournier and Bob Lewis
  1082. for showing us their wavelet light field work.  Finally, we wish to thank Nina
  1083. Amenta for sparking our interest in two-plane parameterizations of lines,
  1084. Michael Cohen for reinforcing our interest in image-based representations, and
  1085. Gavin Miller for inspiring us with his grail of volumetric hyperreality.  This
  1086. work was supported by the NSF under contracts CCR-9157767 and CCR-9508579.
  1087. .sh 1 "References"
  1088. .lp
  1089. .ps 8
  1090. .in 0.25i
  1091. .ne 0.5i
  1092. .ti 0
  1093. [Adelson91]  Adelson, E.H., Bergen, J.R.,
  1094. ``The Plenoptic Function and the Elements of Early Vision,''
  1095. In
  1096. .i "Computation Models of Visual Processing" ,
  1097. M. Landy and J.A. Movshon, eds., MIT Press, Cambridge, 1991.
  1098. .ne 0.5i
  1099. .ti 0
  1100. [Ashdown93]  Ashdown, I.,
  1101. ``Near-Field Photometry: A New Approach,''
  1102. .i "Journal of the Illuminating Engineering Society" ,
  1103. Vol. 22, No. 1, Winter, 1993, pp. 163-180.
  1104. .ne 0.5i
  1105. .ti 0
  1106. [Beers96]  Beers, A., Agrawala, M., Chaddha, N.,
  1107. ``Rendering from Compressed Textures.''
  1108. In these proceedings.
  1109. .ne 0.5i
  1110. .ti 0
  1111. [Benton83]  Benton, S.,
  1112. ``Survey of Holographic Stereograms,''
  1113. .i "Processing and Display of Three-Dimensional Data" ,
  1114. Proc. SPIE, Vol. 367, 1983.
  1115. .ne 0.5i
  1116. .ti 0
  1117. [Blinn76]  Blinn, J.F., Newell, M.E.,
  1118. ``Texture and Reflection in Computer Generated Images,''
  1119. .i "CACM" ,
  1120. Vol. 19, No. 10, October, 1976, pp. 542-547.
  1121. .ne 0.5i
  1122. .ti 0
  1123. [Bolles87]  Bolles, R., Baker, H., Marimont, D.,
  1124. ``Epipolar-Plane Image Analysis:
  1125. An Approach to Determining Structure from Motion,''
  1126. .i "International Journal of Computer Vision" ,
  1127. Vol. 1, No. 1, 1987, pp. 7-55.
  1128. .ne 0.5i
  1129. .ti 0
  1130. [Chen93]  Chen, S.E., Williams, L.,
  1131. ``View Interpolation for Image Synthesis,''
  1132. Proc. SIGGRAPH '93 (Anaheim, California, August 1-6, 1993).
  1133. In
  1134. .i "Computer Graphics Proceedings" ,
  1135. Annual Conference Series,
  1136. 1993, ACM SIGGRAPH, pp. 279-288.
  1137. .ne 0.5i
  1138. .ti 0
  1139. [Chen95]  Chen, S.E.,
  1140. ``QuickTime VR \(em An Image-Based Approach to
  1141. Virtual Environment Navigation,''
  1142. Proc. SIGGRAPH '95 (Los Angeles, CA, August 6-11, 1995).  In
  1143. .i "Computer Graphics"
  1144. Proceedings, Annual Conference Series, 1995, ACM SIGGRAPH, pp. 29-38.
  1145. .ne 0.5i
  1146. .ti 0
  1147. [Fuchs94]  Fuchs, H., Bishop, G., Arthur, K., McMillan, L.,
  1148. Bajcsy, R., Lee, S.W., Farid, H., Kanade, T.,
  1149. ``Virtual Space Teleconferencing Using a Sea of Cameras,''
  1150. .i "Proc. First International Conference"
  1151. .i "on Medical Robotics and Computer Assisted Surgery" ,
  1152. 1994, pp. 161-167.
  1153. .ne 0.5i
  1154. .ti 0
  1155. [Gersho92]  Gersho, A., Gray, R.M.,
  1156. .i "Vector Quantization and Signal Compression" ,
  1157. Kluwer Academic Publishers, 1992.
  1158. .ne 0.5i
  1159. .ti 0
  1160. [Gershun36]  Gershun, A.,
  1161. ``The Light Field,''
  1162. Moscow, 1936.  Translated by P. Moon and G. Timoshenko in
  1163. .i "Journal of Mathematics and Physics" ,
  1164. Vol. XVIII, MIT, 1939, pp. 51-151.
  1165. .ne 0.5i
  1166. .ti 0
  1167. [Gortler96]  Gortler, S.J., Grzeszczuk, R., Szeliski, R., Cohen, M.,
  1168. ``The Lumigraph.''
  1169. In these proceedings.
  1170. .ne 0.5i
  1171. .ti 0
  1172. [Greene86]  Greene, N.,
  1173. ``Environment Mapping and Other Applications of World Projections,''
  1174. .i "IEEE Computer Graphics and Applications" ,
  1175. Vol. 6, No. 11, November, 1986, pp. 21-29.
  1176. .ne 0.5i
  1177. .ti 0
  1178. [Greene94]  Greene, N. and Kass, M.,
  1179. ``Approximating Visibility with Environment Maps,''
  1180. Apple Technical Report No. 41, November, 1994.
  1181. .ne 0.5i
  1182. .ti 0
  1183. [Halle94]  Halle, M.,
  1184. ``Holographic Stereograms as Discrete Imaging Systems.''
  1185. .i "Practical Holography" ,
  1186. Proc. SPIE, Vol. 2176, February, 1994.
  1187. .ne 0.5i
  1188. .ti 0
  1189. [Katayama95]  Katayama, A., Tanaka, K., Oshino, T., Tamura, H.,
  1190. ``Viewpoint-Dependent Stereoscopic Display Using Interpolation of
  1191. Multiviewpoint Images,''
  1192. .i "Stereoscopic Displays and Virtual Reality Systems II" ,
  1193. Proc. SPIE, Vol. 2409, S. Fisher, J. Merritt, B. Bolas eds.
  1194. 1995, pp. 11-20.
  1195. .ne 0.5i
  1196. .ti 0
  1197. [Laveau94]  Laveau, S., Faugeras, O.D.,
  1198. ``3-D Scene Representation as a Collection of Images
  1199. and Fundamental Matrices,''
  1200. INRIA Technical Report No. 2205, 1994.
  1201. .ne 0.5i
  1202. .ti 0
  1203. [Levin71]  Levin, R.,
  1204. ``Photometric Characteristics of Light Controlling Apparatus,''
  1205. .i "Illuminating Engineering" ,
  1206. Vol. 66, No. 4, 1971, pp. 205-215.
  1207. .ne 0.5i
  1208. .ti 0
  1209. [McMillan95a]  McMillan, L., Bishop, G.,
  1210. ``Head-Tracked Stereoscopic Display Using Image Warping,''
  1211. .i "Stereoscopic Displays and Virtual Reality Systems II" ,
  1212. Proc. SPIE, Vol. 2409, S. Fisher, J. Merritt, B. Bolas eds.
  1213. 1995, pp. 21-30.
  1214. .ne 0.5i
  1215. .ti 0
  1216. [McMillan95b]  McMillan, L., Bishop, G.,
  1217. Plenoptic Modeling: An Image-Based Rendering System,
  1218. Proc. SIGGRAPH '95 (Los Angeles, CA, August 6-11, 1995).  In
  1219. .i "Computer Graphics"
  1220. Proceedings, Annual Conference Series, 1995, ACM SIGGRAPH, pp. 39-46.
  1221. .ne 0.5i
  1222. .ti 0
  1223. [Miller95]  Miller, G.,
  1224. ``Volumetric Hyper-Reality:
  1225. A Computer Graphics Holy Grail for the 21st Century?,''
  1226. .i "Proc. Graphics Interface '95" ,
  1227. W. Davis and P. Prusinkiewicz eds.,
  1228. Canadian Information Processing Society, 1995, pp. 56-64.
  1229. .ne 0.5i
  1230. .ti 0
  1231. [Moon81]  Moon, P., Spencer, D.E.,
  1232. .i "The Photic Field" ,
  1233. MIT Press, 1981.
  1234. .ne 0.5i
  1235. .ti 0
  1236. [Narayanan95]  Narayanan, P.J.,
  1237. ``Virtualized Reality: Concepts and Early Results,''
  1238. .i "Proc. IEEE Workshop on the Representation of Visual Scenes" ,
  1239. IEEE, 1995.
  1240. .ne 0.5i
  1241. .ti 0
  1242. [Nimeroff94]  Nimeroff, J., Simoncelli, E., Dorsey, J.,
  1243. ``Efficient Re-rendering of Naturally Illuminated Scenes,''
  1244. .i "Proc. Fifth Eurographics Rendering Workshop" ,
  1245. 1994, pp. 359-373.
  1246. .ne 0.5i
  1247. .ti 0
  1248. [Sbert93]  Sbert, A.M.,
  1249. ``An Integral Geometry Based Method for Form-Factor Computation,''
  1250. .i "Computer Graphics Forum" ,
  1251. Vol. 13, No. 3, 1993, pp. 409-420.
  1252. .ne 0.5i
  1253. .ti 0
  1254. [Seitz95]  Seitz, S., Dyer, C.,
  1255. ``Physically-Valid View Synthesis by Image Interpolation,''
  1256. .i "Proc. IEEE Workshop on the Representation of Visual Scenes" ,
  1257. IEEE, 1995.
  1258. .ne 0.5i
  1259. .ti 0
  1260. [Williams83]  Williams, L.,
  1261. ``Pyramidal Parametrics,''
  1262. .i "Computer Graphics (Proc. Siggraph '83)" ,
  1263. Vol. 17, No. 3, July, 1983, pp. 1-11.
  1264. .ne 0.5i
  1265. .ti 0
  1266. [Ziv77]  Ziv, J., Lempel, A.,
  1267. ``A universal algorithm for sequential data compression,''
  1268. .i "IEEE Transactions on Information Theory" ,
  1269. IT-23:337-343, 1977.
  1270. .in 0
  1271. .bp
  1272. .(z C
  1273. \"    [figures \n(LF and \n(VQ, captions contained in .eps file]"
  1274. .PSPIC /u/levoy/lightfigs/lightfields_preview.eps 5.9
  1275. .)z
  1276. .ip " "
  1277.